Classically, hardware design begins with what is known as a design specification, which is typically a textual description of what is to be designed. Conventionally, in “top-down” design, a design specification is used to generate a hardware description language (“HDL”) representation. Examples of HDLs are Verilog (from Cadence of San Jose, Calif.), SystemC (from Synopsys of Mountain View, Calif.) and Very High Speed Integrated Circuit (“VHSIC”) HDL (“VHDL”).
A design described with an HDL is a functional description, which is converted (“synthesized”) into a text-circuit description using one or more synthesizer tools or programs. Tools for mapping, placing, and routing of components/signals are used to implement this synthesis.
In the context of programmable logic devices (PLDs), such as complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs) and other integrated circuits with programmable logic, a design may be implemented with a configuration bitstream. A configuration bitstream may be written to and read from an external memory coupled to the FPGA. Individual memory cells of internal FPGA memory are programmed with such configuration bitstream to cause at least a programmable logic portion of the FPGA to function as the design. For purposes of clarity, an FPGA integrated circuit is described, though it will be apparent that any integrated circuit of sufficient complexity designable with synthesis tools may be implemented.
Complexity and runtime for simulating has increased with an increase in the number of gates on an integrated circuit and with an increase in the number of test vectors used to verify performance, especially with respect to heterogeneous integrated circuits like “System-on-Chips” (SoCs). For example, an FPGA may include one or more embedded cores. Such embedded cores may include one or more digital signal processors (DSPs), microprocessors, microcontrollers, dedicated logic (Application Specific Integrated Circuits (ASICs)), multipliers, and memory, among other known integrated circuits. Adding to this complexity, one or more embedded core designs may be from one or more entities other than the designing entity of the FPGA. For clarity, an FPGA with an embedded DSP is described, though it will be apparent that other SoCs may be used.
Less conventionally, to speed up design simulation, a “high-level” of abstraction simulation has emerged. By “high-level”, it is meant simulation using a programming language in contrast to a “low-level” of abstraction simulation using an HDL representation of a design. For example, hardware-oriented concepts are described in C-code, such as C++, and provided as a library of classes. These classes may be used to model a design specification, which model may be compiled into an executable design file. This executable design file is a software simulation of a design, which may be used to validated design operation prior to implementation of a synthesizable HDL version.
Returning to the above example of a FPGA/DSP SoC, System Generator for DSP from Xilinx of San Jose, Calif., is a software tool for modeling and designing FPGA-based digital signal processing systems developed with MATLAB and Simulink from The MathWorks of Natick, Mass. System Generator for DSP may be used to translate a software simulation of a design into an HDL version of a design, including embedded cores. Accordingly, a software simulation for an SoC is converted into synthesizable HDL for hardware implementation.
However, conventional verification that a software simulation operates equivalently to its hardware implementation counterpart is problematic. Conventionally, a software simulation is run in parallel with its hardware implementation counterpart (“hardware-software co-simulation” or just “co-simulation”), where software simulation and hardware implementation respective results from test vector stimulus are compared at each clock cycle. To ensure a hardware implementation is synchronous with its software simulation counterpart, a gated clock pulse is supplied to the hardware implementation after each simulation step. This type of test clocking is known as “single-step clocking” or “single-step clock.” Running through a set of test vectors using single-step clocking consumes significant amounts of time.
Furthermore, single-step clocking test results do not necessarily reflect operating speed of a hardware implementation, for example, a hardware implementation may operate slower than its software simulation counterpart. Thus, once a designer is satisfied that a hardware implementation meets some threshold of functional equivalence with its software simulation counterpart, as evidenced by a successful run through of a set of test vectors with single-step clocking, test time for simulating the hardware implementation and the software simulation may be reduced by applying a “free-running” clock signal. By “free-running” clock signal, it is meant that clock pulses are provided with periodicity not related to gating, where each pulse in a single-step clock signal is deterministically or controllably applied. Thus, if gated, a free-running clock signal is provided to an implemented design in a pass through manner in contrast to a single-step clock.
Application of a free-running clock facilitates both loading more test vectors than single-step clocking and facilitates determining maximum operating speed of the hardware implementation. However, use of a free-running clock signal means that clock domains of co-simulated software simulation and hardware implementation are not coupled. Thus, test data input and test data output sampling is done asynchronously, making test data correlation between software simulation and hardware implementation cumbersome.
Accordingly, it would be both desirable and useful to provide simulation means that involves less time intensive test data correlation as compared with a single-step clocking test mode and where there is improved test data correlation as compared with a free-running clocking test mode.